AA is mainly applied to redundancy and backup of data in an AA cluster system. The AA cluster system includes a host cluster, several storage arrays, and a quorum server. For example, the several storage arrays include a storage array A and a storage array B. When the AA cluster system normally runs, the host cluster may deliver read/write services both to the storage array A and the storage array B. When the host cluster needs to deliver a write service to the storage array A, a host in the cluster system first delivers write data to the storage array A, and then the storage array A writes the delivered data both to the storage array A and the storage array B. After the data write to both the storage array A and the storage array B is completed, the storage array A returns data write completion to the host. A data write process of the host cluster on the storage array B is similar to the foregoing basic procedure. When split-brain occurs in the storage array A and the storage array B, that is, a communication fault occurs between the storage array A and the storage array B, one storage array in the AA cluster system may automatically take over the service to avoid service downtime and a data loss. For example, the host delivers data to the storage array A, a communication fault occurs between the storage array A and the storage array B, and the storage array A and the storage array B separately initiate a quorum request to the quorum server after the fault is detected. The quorum server determines, according to logic judgment to enable the storage array A to take over the service, and returns quorum results in response to the storage array A and the storage array B. Although it is determined that the storage array A takes over the service, the data delivered by the host to the storage array A is not synchronized to the storage array B because of the fault between the storage array A and the storage array B. If the storage array B is not disconnected from the host when the storage array A takes over the service, data that is read by the host from the storage array B is erroneous data, resulting in input/output (I/O) fencing. In other approaches, to ensure data consistency between the storage array A and the storage array B, an agreement is made between the storage array A and the storage array B using software, and it is required that the storage array B should stop the service before the storage array A unilaterally provides a service. For example, it is agreed that, when detecting that the storage array B cannot perform communication, the storage array A can receive the service only after 10 seconds to ensure that the storage array B has stopped the service before the storage array A unilaterally provides a service.
In the other approaches, there are at least the following problems. In the other approaches, there is a strict requirement on a time sequence of the storage array A and the storage array B. However, during actual running of the storage arrays, there are some uncontrollable factors. For example, the storage array B cannot stop the service in time because of excessive system central processing unit (CPU) usage, a network latency, or the like. As a result, out-of-order of a time sequence and data inconsistency between the storage arrays occur, causing I/O fencing.